• SCHOOL 

uL'I CAT ■ • 0 ‘, '-vnOO^ 



NAVAL POSTGRADUATE SCHOOL 

icntsrey , California 




THESIS 



AN INTELLIGENT COMPUTER-ASSISTED INSTRUCTION SYSTEM 
FOR CARDIOPULMONARY RESUSCITATION 



by 



Debra S. Campbell 

i t / 

June 1988 



Thesis Advisor: 



Neil C. Rowe 



Approved for public release; distribution is unlimited 



T238747 



n k.i v/ i«i k/ v vwiTik.fi i i • w « 



la. REPORT SECURITY CLASSIFICATION 
Unclassified 



lb RESTRICTIVE MARKINGS 



la. SECURITY CLASSIFICATION AUTHORITY 



’b. DECLASSIFICATION 'DOWNGRADING SCHEDULE 



3 DISTRIBUTION /AVAILABILITY OF REPORT 

Approved for public release; 
Distribution is Unlimited 



1. PERFORMING ORGANIZATION REPORT NUM3ER(S) 


5 MONITORING ORGANIZATION REPORT NUMBER(S) 


6a. NAME OF PERFORMING ORGANIZATION 
Naval Postgraduate School 


6b OFFICE SYMBOL 
(If applicable) 
Code 52Rp 


7a NAME OF MONITORING ORGANIZATION 
Naval Postgraduate School 


6c. ADDRESS (C/ty, State , and ZIP Code) 

Monterey, California 93943-5000 


7b. ADDRESS (City, State, and ZIP Code) 

Monterey, California 93943-5000 


8a. NAME OF FUNDING / SPONSORING 
ORGANIZATION 


8b. OFFICE SYMBOL 
(If applicable) 


9. PROCUREMENT INSTRUMENT IDENTIFICATION NUMBER 


8c. ADDRESS (City, State, and ZIP Code) 


10 SOURCE OF FUNDING NUMBERS 



PROGRAM 


PROJECT 


TASK 


WORK UNIT 


ELEMENT NO. 


NO 


NO 


ACCESSION NO 



11. TITLE (Include Security Classification) 

AN INTELLIGENT COMPUTER-ASSISTED INSTRUCTION SYSTEM FOR CARDIOULMONARY RESUSCITATION 



12. PERSONAL AUTHOR(S) 

Campbell, Debra S. 



13a. TYPE OF REPORT 


13b TIME COVERED 


14 DATE OF REPORT {Year, Month. Day) 


15 PAGE COUNT 


Master’s Thesis 


FROM TO 


1988 June 


145 



16. SUPPLEMENTARY NOTATION 



17 


COSATI 


CODES 


18 SUBJECT TERMS ( Continue on reverse if necessary and identify by block number) 


FIELD 


GROUP 


SUB-GROUP 


Intelligent Computer-Assisted Instruction (ICAI) 
Computer-Based Instruction (CBI) 















19. ABSTRACT ( Continue on reverse if necessary and identify by block number) 



This study discusses the design and implementation of an Intelligent Computer-Assisted 
Instruction system for cardioulmonary resuscitation. Utilizing artificial-intelligence 
techniques, the system combines a learning-while-doing environment with effective guidance 
of tutorial interactions. 

The user’s knowledge of CPR procedures is tested at one of three experience levels, 
utilizing a randomly generated scenario. Using means-ends analysis, the recommended action 
is determined for each successive state in the scenario. This action is compared with the 
user’s selection. If a difference exists, an hypothesis guides the tutoring module in the 
selection of a tutoring strategy. 

An on-line review of CPR procedures is available, as is a help function to provide 
direction to the user if needed. At the end of a session, a summary of the user’s actions 
is provided. 



20 DISTRIBUTION/AVAILABILITY OF ABSTRACT 

C3 UNCLASSIFIED/UNLIMITED □ SAME AS RPT □ OTIC USERS 


21. ABSTRACT SECURITY CLASSIFICATION 
Unclassified 


22a. NAME OF RESPONSIBLE INDIVIDUAL 
Prof. Neil C. Rowe 


22b TELEPHONE (Include Area Code) 

(408) 646-2462 


z2c. OFFICE SYMBOL 
Code 52Rp 



DD FORM 1473, 84 mar 



83 APR edition may be used until exhausted 



SECURITY CLASSIFICATION OF THIS PAGE 



All other editions are obsolete 



U.S. Government Printing Office: 1986 — 606- 



UNCLASSIFIED 



i 



Approved for public release; distribution is unlimited. 



AN INTELLIGENT COMPUTER-ASSISTED INSTRUCTION SYSTEM 

for 

CARDIOPULMONARY RESUSCITATION 

by 

Debra S Campbell 

Lieutenant Commander, United States Navy 
B.A., University of Washington, 1976 

Submitted in partial fulfillment of the 
requirements for the degree of 

MASTER OF SCIENCE IN COMPUTER SCIENCE 

from the 

NAVAL POSTGRADUATE SCHOOL 
June 1988 



ABSTRACT 



This study discusses the design and implementation of an Intelligent Computer- 
Assisted Instruction system for cardiopulmonary resuscitation. Utilizing artificial- 
intelligence techniques, the system combines a learning-while-doing environment with 
effective guidance of tutorial interactions. 

The user’s knowledge of CPR procedures is tested at one of three experience levels, 
utilizing a randomly generated scenario. Using means-ends analysis, the recommended 
action is determined for each successive state in the scenario. This action is compared 
with the user’s selection. If a difference exists, an hypothesis is formulated concerning 
the cause and severity of the difference. This hypothesis guides the tutoring module in 
the selection of a tutoring strategy. 

An on-line review of CPR procedures is available, as is a help function to provide 
direction to the user if needed. At the end of a session, a summary of the user’s actions is 
provided. 
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THESIS DISCLAIMER 



i 



The reader is cautioned that computer programs developed in this research may not 
have been exercised for all cases of interest. While every effort has been made, within 
the time available, to ensure that the programs are free of computational and logic errors, 
they cannot be considered validated. Any application of these programs without 
additional verification is at the risk of the user. 
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I. INTRODUCTION 



Computer-based instruction can dramatically alter the way we learn and teach. A 
significant advantage of using the computer in the realm of education and training is that 
it allows for interactive learning for all students. The needs of each student can be met 
by individualizing the learning experience. In the typical classroom environment there 
are relatively few opportunities for such interaction between the teacher and the student. 
Private human tutors can provide this one-on-one interaction; however, they can be cost- 
prohibitive. The human tutor is also limited in the knowledge they can possess. 
Computerized instructors, however, can capture the knowledge of many experts and can 
provide interactive, individualized instruction. 

With such enormous potential, one might ask why computers have not had more of 
an impact in the world of education. Computer-based instruction has been available for 
many years. The impact of this instructional media, however, has been small. There are 
many possible reasons for this lack of positive impact. One answer lies in the ability to 
think. The processes of teaching and learning are fundamentally cognitive activities. To 
successfully teach, computers must be able to capture the skill of "thinking". 

The intent of this thesis is to explore the feasibility of instruction via a "thinking" 
computer utilizing cardiopulmonary resuscitation (CPR) as the application domain. The 
reason for this choice of application is its real life applicability to a wide range of 
students. 

A. CPR 

The leading cause of death in the United States is cardiovascular disease. It is 
estimated that a million and a half Americans will have heart attacks each year and one 
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third of these people will die. This equates to a death rate of 1500 people every day from 
heart attacks alone. In addition to heart attacks, victims of other situations such as 
drowning accidents, electrocution, drug overdose and poisoning may also go into cardiac 
arrest. Most of these victims who die from a cardiovascular failure do so before they 
ever reach trained medical personnel and emergency equipment. It is therefore the 
chance bystander who can play a critical role in reducing this death rate by being able to 
recognize cardiac emergencies, provide proper first aid, and call for medical services. 

If a person’s heart stops for any reason, cardiopulmonary resuscitation (CPR) must 
be started immediately. CPR is needed to keep oxygen supplied to the brain and other 
body organs until more advanced emergency medical treatment is available. Knowing 
how to immediately provide correct CPR procedures when confronted with an 
emergency can mean the difference between life and death for many victims. [Ref. 1] 

Formal CPR classes are an important method for teaching these correct procedures. 
Demonstrated public interest in learning CPR is high and more people are being trained 
in the correct procedures. However, in most cases when a cardiac arrest occurs, CPR is 
not started by bystanders, but is delayed until trained medical personnel arrive on the 
scene. This suggests that even people trained in correct CPR procedures may lack the 
confidence to use their skills in an emergency. [Ref. 2] 

It is the intent of this thesis to provide an intelligent computer- assisted instruction 
system, not to replace currently available CPR courses, but to supplement them. This 
one-on-one tutoring is designed to raise the confidence level of the user so that when 
confronted with an emergency, critical minutes will not be lost. An intelligent 
computer-assisted instruction system can offer several unique advantages over the more 
traditional classroom approaches. The 24-hour availability of such a system affords the 
user the scheduling flexibility of receiving training at their convenience. The system, 
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unlike a human tutor or instructor, never loses patience with the student and can provide 
undivided attention at all times. The system also has the capability to test the student on 
unusual occurrences, many of which are more likely to occur when the student is allowed 
to pursue their own ideas rather than be streamlined through the correct or "logical" 
sequence of actions. 

B. METHODOLOGY 

In designing and implementing a computerized instruction system for CPR, 
henceforth referred to as the CPR Tutor, artificial intelligence (AI) techniques 
implemented in the Prolog programming language were utilized. A computer program 
such as this is referred to as intelligent computer-assisted instruction (ICAI) system or an 
intelligent tutoring system (ITS). Both terms will be used interchangeably throughout 
this study. The development of such a system focuses primarily on the problems of 
knowledge representation, student misconceptions, and inferencing [Ref. 3]. 

The basic components of the CPR Tutor are the student model, the expert module, 
the tutor module, and the user interface. The student model represents what the student 
does or does not know. The comparison of the student model with the expert module 
generates discrepancies that are analyzed by the tutor. The tutor provides appropriate 
feedback and updates the student model accordingly. The user interface serves as a 
buffer between the user and the CPR Tutor. 

Programmed with information provided by the American Red Cross [Ref. 1], the 
CPR Tutor can randomly generate various emergency situations. The situation is 
displayed to the user as a list of facts. The CPR Tutor can prompt the user for an action 
in the stated situation, require a more detailed description of the action from the user, or 
provide assistance to the user in selecting the most correct action. After the user has 
entered their action selection in the given situation, the CPR Tutor will compare the 
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user’s choice with that of the expert module. Based on this comparison, the user gets 
immediate results of their action in the form of a positive acknowledgement for the 
preferred response, a warning statement of varying severity for an incorrect response, or 
a message indicating the users response differs from the expert but the system will pursue 
the user’s approach to the situation. 

The CPR Tutor was organized into four primary files: cpr, mecpr, metutor, and 
utilities. The cpr, mecpr, and a portion of the utilities files were developed by the author 
to provide the CPR domain knowledge as well as the overall structure of the user 
interface. This Prolog code was developed to operate in conjunction with a generic 
means-ends analysis tutoring system, metutor, developed by Professor Rowe of the Naval 
Postgraduate School. Minor modifications were made to the metutor file to accommodate 
a menu-driven user interface and to include a limited amount of CPR domain specific 
tutorial responses in addition to the general tutoring strategies already present. 

C. PREVIEW 

Chapter II provides background information on CPR and the method by which it is 
currently taught by the American Red Cross . 1 Also included is a description of the the 
training format used in the American Red Cross Adult CPR course. Chapter in provides 
a background on computer-assisted instruction (CAI). This includes a review of 
computer-based instruction (CBI) and intelligent computer-assisted instruction (ICAI); 
these two are compared and contrasted, and specific applications of each are introduced. 
Chapter IV discusses the actual design and implementation of CPR Tutor. Chapter V 
discusses use of the CPR Tutor. Issues of expandability and portability of the system are 
addressed, as well as limitations and benefits of the system. Chapter VI is the summary 



'See References 1 and 2 for a detailed description of these procedures. 
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and provides a final discussion of the research questions. Appendices A through C 
present user sessions. Demonstrations are offered at each of the three user levels: novice, 
intennediate, and advanced. Appendix D contains the Prolog source code for CPR Tutor 
developed by the author. Appendix E contains the Prolog source code developed by 
Professor Rowe. 
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II. OVERVIEW OF COMPUTER-ASSISTED INSTRUCTION 



A. BACKGROUND 

The use of the computer for teaching dates back to the late 1950s. The most 
common label for computer assistance in teaching and in the learning process is CAI, 
referring to computer-assisted instruction or, equally commonly, computer-aided 
instruction. CBI, computer-based instruction, is also used in reference to this same 
instruction. Other labels which are used include CAL, where "learning" replaces 
"instruction" and thus places a greater emphasis on the activities initiated by the learner 
than on the instructional materials created by the teacher-author. Replacing "instruction" 
with "education" as in CAE or CBE, computer-based education, similarly shifts die 
implication to infer a wider variety of computer uses, including administrative data 
processing and materials production as well as student use of computers. If emphasis is 
to be placed on the computer assisting the teacher in managing instruction, computer- 
managed instruction, CMI, is the more appropriate label. [Ref. 4] 

Intelligent computer-assisted instruction, ICAI, refers to the more recent fonn of 
computer delivered instruction. ICAI utilizes artificial intelligence technology applied to 
instruction. To provide greater distinction and differentiation between this more recent 
approach and the older, more traditional ones, the descriptive phrases ICAI and CBI will 
be used throughout the remainder of this study. 

B. COMPUTER-BASED INSTRUCTION 

Traditional computer-based instructional systems tend to be designed and 
implemented by educational psychologists or technologists. Designed to solve practical 
problems by applying computer technology, a basic theme of CBI is that "the computer is 
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neither instruction nor a method of instruction; it is merely a vehicle of instruction". 

[Ref. 5] Although many different types of instructional strategies have been applied in 
CBI, the most prevalent have been based on the common approaches practiced in schools 
and training environments. The basic principle being that the instructor should 
successfully communicate their knowledge to the student to achieve the objectives within 
the imposed constraints. The success of the system is primarily detennined by its degree 
of instructional effectiveness and efficiency. This teacher-centered approach requires the 
student to first understand the teacher’s instruction and reinforce this understanding 
through practice. In this approach, the student has little or no initiative in the 
instructional process [Ref.3:pp.24-29J. 

The early CBI systems were developed primarily as a supplement to the principal 
instructional process. Taking the form of programmed-instruction paradigms, the 
formats of these systems were either electronic "page turners", which simply printed 
prepared text, or drill-and-practice, which printed problems and utilized prestored 
answers and remedial comments to respond to the student’s solution [Ref.6:p.225]. As 
CBI has since evolved to become a main instructional delivery system, as opposed to 
merely a supplemental system, the format has diversified. In addition to the drill-and- 
practice approach, CBI formats now include tutorial, games, and simulations. 

C. ICAI SYSTEMS 

ICAI is a more recent form of computer-assisted instruction. Evolving from the 
field of computer science, it is an example of the application of artificial-intelligence 
technology to instruction. The basic philosophies underlying the structures and 
development processes are therefore fundamentally different from traditional CBI. The 
focus of ICAI projects has been on the technical and instructional aspects of the system 
as opposed to the domain features. Many ICAI projects have, however, also sought to 
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better understand the cognitive processes involved in learning and teaching. It can thus 
be asserted that ICAI programs actually lie at the intersection of computer science, 
cognitive psychology, and educational research. [Ref. 3] 

1. Structural Methodology 

Although ICAI programs often bear little outward resemblance to each other, 
most of these systems deal with similar issues and contain similar functional 
components. A typical ICAI system contains three primary components: the 
representation of knowledge, the provision of instruction, and the modeling of learning 
behavior. These components are commonly referred to as the expert module, the tutor 
module, and the student model respectively. In addition to these three components, a 
student interface is also necessary. Figure 2. 1 depicts a generalization of the components 
in an ICAI system [Ref. 3], 

a. Expert Module 

Tire expert module is the encapsulation of the domain expert, containing 
the knowledge that the system is attempting to impart to the student. It is this module 
that generates "problems" and is used to evaluate the correctness of the student response. 
If a fully developed ICAI system is to be maximally effective, several experts in the 
domain should be members of the development team, to overcome the incomplete 
knowledge or conceptual vacuums that are often present in a sole expert. The domain 
knowledge found in textbooks is also often incomplete as well as idealized and, as such, 
is inappropriate as the primary knowledge source for a truly effective and operational 
ICAI system. [Ref. 7] 

b. Tutor Module 

A distinguishing feature of ICAI systems is the separation of the expert 
knowledge from the teaching strategies. An AI system that is an expert in a particular 
domain is not necessarily an expert teacher of the same domain. The acquisition of 
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Figure 2.1 ICAI System Components 



sufficient and correct teaching expertise has been a long-teim problem for builders of 
tutoring systems [Ref. 7], Multiple teaching strategies exist and no single strategy is 
appropriate for every domain. Each state in the domain, as well as each student, must be 
assessed if an appropriate teaching strategies are to be employed. It is therefore the task 
of the teaching expert, the tutor module, to choose the next strategy. This includes 
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providing diagnostics, questioning the student further or in more detail, and presenting 
new information. A central issue in the design of this module is the appropriateness of 
providing immediate responses to the student’s action as opposed to temporarily 
allowing the student to continue down an incorrect path without interruption. 

ICAI systems mainly use two types of instructional strategies although 

many other strategies do exist and have been used. The two basic classifications are the 

Socratic, tutorial method and the coaching method. The Socratic method involves 

questioning the student and guiding them through the process of debugging their own 

misconceptions. Wenger [Ref.8:p.39] summarizes this method by stating: 

In the Socratic method, the tutor does not teach a subject by direct exposition, but leads 
the student by successive questions to formulate general principle on the basis of 
individual cases, to examine the validity of her own hypothesis, to discover 
contradictions, and finally to extract correct inferences from the facts she knows. 

The student is thus encouraged to reason about what they know and thereby modify their 

conceptions. 

The goal of coaching is to encourage the acquisition of skills and general 
problem-solving abilities by engaging the student in activities such as computer games. 
The immediate aim of the student is to have fun; skill acquisition and learning is, by 
design, an indirect consequence. Tutoring comes about through appropriate interruptions 
by the coach that offer new information or suggest new strategies. Primary challenges in 
using this instructional method lie in being able to "observe" the student’s play of the 
game, determining what skills or knowledge the student is likely to acquire based on 
their playing skills, and judging effective times and means for intercession. 
[Ref.6:pp. 233-235] 

c. Student Model 

The primary focus of the student model is to represent what the student 
does and does not know, or the student’s understanding of the material being taught. The 
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purpose of modeling the student is to enable specific assessments to be made of the 
student’s knowledge of the domain and to hypothesize about their misconceptions and 
the reasoning strategies they employed. The tutor module is thereby able to point out 
misconceptions and make suggestions. The model is generally constructed by comparing 
the student’s response in a given state to that of the expert in the same state, the expert 
being contained in the expert module. This techniques is referred to as the "overlay 
model." [Ref. 3 :p. 17] 

2. Applications 

The impetus of the development of ICAI systems was SCHOLAR , a Socratic 
tutor designed to teach students about South American geography. It was the pioneering 
effort in the development of tutorial dialogues capable of handling unanticipated student 
questions and of generating instructional materials in varying levels for the student. 
Developed in the 1970, SCHOLAR is on of the earliest ICAI systems and, as such, was 
instrumental in setting the basic themes and goals for the field. [Refs. 6, 8] 

An extension of SCHOLAR, WHY tutors students in the causes of rainfall. 
Also implementing the Socratic tutoring method, WHY made the effort to describe the 
global strategies used by human tutors to guide the tutorial dialogue. Although it 
remained primarily theoretical, WHY represented the first attempt at capturing a 
complete tutorial strategy as complex as the Socratic method in a concise, rule-based 
computational model. [Refs.6, 8] 

SOPHIE was developed to explore the student initiative during the tutorial 
interaction. The pedagogical purpose in SOPHIE was to provide a reactive learning 
environment in which the student could try out their own ideas, have them critiqued, and 
receive advice. Set in the domain of troubleshooting electronic circuits, this program 
allowed the student the chance to apply their theoretical knowledge of electronic laws in 
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a simulated electronics laboratory. Students were challenged to explore their own ideas 
and to come up with conjectures or hypotheses about troubleshooting strategies for 
electronic circuits. The role of the expert was to provide detailed feedback as to the 
logical validity of their proposed solutions. With roots going back to the early 1970s, 
SOPHIE went through three successive phases spanning more than five years. The 
research it spawned continues today. [Refs. 8, 9] 

Initiated in the context of SOPHIE, which was originally meant to include a 
troubleshooting coach, WEST was the first ICAI system to use the coaching strategy. 
The domain of electronics was viewed as too complex for a first computer-based 
investigation into the strategy of coaching, hence WEST was developed to coach 
students in elementary arithmetic. Another ICAI system that used the coaching strategy 
was WUMPUS, which challenged the student in the domains of logic, probability, 
decision theory and geometry. [Refs. 6, 9] 

GUIDON was a program developed to teach diagnostic problem-solving. Its 
mixed-initiative dialogue differs from the other ICAI systems listed above in its use of 
prolonged, structural teaching. It went beyond simply responding to the student’s last 
move, the methodology used in WEST and WUMPUS, and the repetitive questioning 
and answering technique used in SCHOLAR and WHY. The uniqueness of GUIDON, 
however, was in its attempt to turn an existing expert system, MYCIN, into an intelligent 
tutor. GUIDON demonstrated the inappropriateness of using just an expert system’s 
knowledge base as the expert module of an ICAI system without supplementation to help 
explain and organize the knowledge in the process of teaching. [Refs. 6, 9] 

While a complete ICAI system has the three primary components, not all 
systems do. PROUST and STEAMER are two such examples: they do not contain 
tutoring functions. PROUST is a knowledge-based system to find nonsyntactic bugs in 
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Pascal programs written by beginning programmers. The key idea of STEAMER is the 
conception of an interactive inspectable simulation of a steam propulsion system. Its 
primary concern is how people understand and reason about complex systems as well as 
how interactive graphical interfaces might support the development of useful mental 
models. Started in the late 1970s, STEAMER is not yet an operational system. However, 
it is considered of significant importance in the field of ICAI because it called for a very 
careful look at what aspects of AI technology are actually ready for application in the 
design and implementation of an instructional system. [Ref. 3] 

OBIE-l:KNOBE was the first generic system to enable the construction of 
realistic, dynamic representations of real devices. Intelligent simulations previous to it 
were not generalized. They were specifically designed and built with only the immediate 
subject domain in mind. [Ref. 10] 

One system which has been fully implemented, tested and is in use, although 
still being augmented based on formal student evaluations, in nearly sixty industrial sites 
across the United States is RBT, Recovery Boiler Tutor. The tutor is based on a 
mathematical formulation of a type of boiler found in paper mills. It provides an 
interactive simulation in which emergencies can result from inappropriate student 
responses. An unusual point about this system is its use of Fortran and C as the 
implementation languages. [Ref. 7] 

D. COMPARISON AND CONTRAST OF CBI AND ICAI 
1. Focus 

Traditional CBI has been developed primarily by educational psychologists 
and technologists. The role of the computer has generally been that of a vehicle for 
efficient implementation. As an older, more established field, textbooks are available 
which suggest detailed guidelines, procedures and principles which should be followed in 
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designing a CBI system. The overall goal of a CBI system is thus the usability of an 
effective and efficient system [Ref. 5]. 



ICAI, in contrast, has primarily been a computer science initiative in the 
application of AI technology in the educational/instructional process. The focus has been 
on the technical aspects such as knowledge representation techniques, inferencing 
mechanisms, natural language dialogues, etc. 

2. Subject Matter Domain 

CBI systems have been developed for a wide range of subject areas, including 
math and sciences as well as the arts. The subject matter is, in fact, virtually unlimited. 
The application domain of ICAI systems have generally been limited to subject areas 
which are themselves relatively well-structured. With the emphasis being on the AI 
technology rather than a specific domain, subject matter areas have primarily been 
selected due to their appropriateness for the AI technique being researched. The 
emphasis has thus been more on the process itself, rather than the end result. 
[Ref.3:p.28] 

3. Fonnat 

The early CBI programs were used generally as a supplement to the principal 
instructional method 'The basic fonnat was drill and practice, serving to reinforce the 
material that was previously presented by the instructor. CBI has since evolved into a 
main instructional delivery system and the fonnat has correspondingly diversified. 
Common CBI formats now include intrinsic and extrinsic games; physical, situational, 
and process simulations; and tutorials in addition to drill and practice. [Ref.3:p.27] 

ICAJ does not tend to use the simulation nor the drill and practice fonnats. 
Instead, these systems tend to fall into the category of either a tutorial or a game. 
Although both CBI and ICAI systems use these latter two formats, the methodology and 
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purpose are different. In a CBI tutorial, the questions are used to reinforce the material 
that has been provided by computer-based instruction. These questions are always 
initiated by the system, answered by the student, and are directly related to the presented 
material. The computer does not "know" the subject matter but merely presents blocks of 
text. Questions are posed to the student based on a predetermined algorithmic process. 
ICAI systems, on the other hand, take a more dynamic approach. Attempting to carry on 
a series of question and answer exchanges, many ICAI systems can carry on a natural 
language, or pseudo-natural language, dialogue with the student. Not only does the 
system ask questions of the student, but the student is also able to direct questions to the 
system. In addition to allowing greater flexibility, ICAI systems utilize these question- 
and-answer exchanges to make a determination of what the student understands and 
direct the instructional process accordingly. [Ref.3:pp.24-27] 

Intrinsic games are used in CBI as a means of teaching gaming rules and/or 
skills. Extrinsic games are used primarily to maintain the motivation of the student. The 
use of games in ICAI systems is similar to the use of extrinsic games in CBI systems, the 
purpose being to provide a "reactive learning environment". The difference is that in 
ICAI systems, students are expected to develop a higher level of knowledge. The games 
are generally designed to allow the student the ability to explore and test their own ideas 
and thus, control the instructional process to a greater degree. [Ref.3:pp.27-28] 

4. System Design Structure 

Traditional CBI structure is frame-oriented. It is organized as a file of screens 
to be presented to the student. A more dynamic approach is taken by an ICAI system. 
The design structure is the combination of a knowledge database with a transaction 
series for using the database [Ref. 11]. Thus, a distinguishing feature of ICAI systems is 
the separation of the teaching strategy(s) from the subject expertise to be taught [Ref. 6]. 
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5. Development Process 



The development of most CBI programs has utilized a systems 
approach [Ref. 5]. This approach requires several steps of procedural activities. 
Included in this process is a needs analysis, followed by the design and development as 
well as the implementation. Evaluations are conducted throughout the various stages. 

No such generalized procedure can describe the development of ICAI systems. 
In addition to the fact that very few ICAI systems have been chronologically or 
systematically documented, the inherent difference in goals plays a significant role. The 
development of each ICAI system has been guided by the specific goals and skills of the 
individual researchers as well as the actual characteristics of the application domain. The 
development process has, therefore, varied among the various ICAI projects. 

In comparing the development time required for CBI and ICAI, it is estimated 
that the first hour of a CBI system requires approximately two hundred hours of 
programmer preparation, an amount probably exceeded by the preparation time required 
for an ICAI system. Each additional hour of instruction in a CBI system requires an 
additional two hundred hours of programmer preparation. ICAI systems, by comparison, 
are designed to utilize a single piece of knowledge in many ways. Therefore, each 
additional hour of instruction can be expected to require relatively less programmer 
preparation time. [Ref. 7] 

6. Hardware and Software 

A driving force in the development of computer delivered instruction has 
always been the evolution of computer technology. CBI systems of the 1960s and 1970s 
utilized special computer systems developed primarily for CBI, such as PLATO, 
TICCIT, and IBM 1500. Each of these early systems also has their own programming 
language specifically designed for authoring CBI systems. These were, respectively. 
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TUTOR, APT/TAL and Coursewriter. These systems, with the exception of IBM 1500, 
are still in use today. With much lower associated costs, microcomputers, however, have 
become the most commonly used system for both development and implementation. In 
addition to the system-specific languages, three other levels of software are currently 
used. These are: 1) general-purpose languages such a Pascal, C, FORTRAN and BASIC, 
2) system-independent CBI languages, and 3) authoring systems that provide facilities, 
without requiring programming skills to develop CBI courses of instruction. Although 
exceptions exist, ICAI systems, with their emphasis on the application of AI technology, 
have primarily been developed on special AI hardware or computers supporting an AI 
language. The software has been, for the most part, limited to LISP and Prolog. 
[Ref.3:pp.29-30] 
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m. OVERVIEW OF CPR 



It is estimated that one out of every five Americans has some form of cardiovascular 
disease and one out of every two people will die from a heart attack or a related disease. 
As such, it is the leading cause of death in the United States. It is estimated that forty 
percent of cardiac arrest victims could be saved if CPR was immediately provided and 
the initiation of advanced life support measures by qualified medical personnel followed 
within eight to ten minutes. [Ref. 1J 

A. PURPOSE 

Cardiopulmonary resuscitation is the combination of artificial respiration and 
manual artificial circulation. It is a means of supplying oxygen to the body when a 
person’s heart has stopped. By breathing oxygen into the victim’s lungs, oxidated blood 
can then be circulated through the victim’s body by manually compressing and releasing 
on the lower half of the sternum. CPR does not "revive" victims nor does it restart the 
heart. CPR does, however, provide critical life-sustaining oxygen to the brain and other 
body organs until advanced life support systems provided by professional medical 
personnel can get the heart restarted. Thus, the twofold purpose of CPR is 1) keeping the 
lungs supplied with oxygen when breathing has stopped and 2) keeping blood circulating 
and carrying oxygen to the brain, heart, and other body parts. [Ref. 1J 

B. PROCEDURES 

Cardiopulmonary resuscitation is a combination of rescue breathing in which 
oxygen is artificially breathed into the victim and manual chest compressions which keep 
oxygen-carrying blood flowing through the blood vessels. The external cardiac 
compressions consist of the application of rhythmic pressure over the lower half of die 
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sternum, compressing the heart and producing a pulsatile artificial circulation. Artificial 
ventilation achieved through rescue breathing must always be provided in conjunction 
with external cardiac compressions. [Ref. 1] 

To achieve maximum effectiveness in the performance of CPR, actions by the 
rescuer must be deliberate and precise. Attention to detail is vital. The order of actions 
and the number of repetitions is not arbitrary. The following paragraphs list the actions, 
henceforth referred to as operators, which are the basics of CPR. Figures 3.1 and 3.2 
summarize the sequencing of actions. 

Check unconsciousness is the first operator recommended in the process of 
providing CPR. The determination of consciousness or unconsciousness will dictate 
which further actions may be required. Although a conscious person may require first 
aid, CPR is not applicable. If the person should lose consciousness and no pulse nor 
breathing is observed, CPR should be initiated immediately. 

Yell for help is performed to beckon assistance. If assistance is available, they can 
be instructed to phone emergency medical services. If assistance is not available, it will 
be necessary for the rescuer to perform CPR for at least one minute and then temporarily 
cease CPR to contact the paramedics personally. This operator is ideally performed after 
unconsciousness is checked. However, it can also be correctly applied prior to the check 
unconsciousness operator. 

Position victim is a prerequisite to to the proper performance of CPR. It is 
impossible to accurately judge whether or not a victim is breathing unless they are on 
their back. Chest compressions also require the victim to be on their back. 

For breaths provided by the resuer to be effective, the airway must be open. 
Therefore, it is necessary for the rescuer to perfonn the operator open airway. 
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Figure 3.1 CPR Procedural Flowchart - Part One 
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Figure 3.2 CPR Procedural Flowchart - Part Two 
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If a person is breathing, CPR is never applicable. In fact, performing chest 
compressions on a breathing victim may result in serious injuries. Prior to performing 
CPR on an unconscious person it is therefore necessary to check for breathing. 

Standby to assist is not an actual CPR operator. It is performed only as a default. 
It is used when the victim is breathing and is not bleeding. 

The operator give two breaths is performed multiple times throughout the CPR 
process. When breathing ceases, artificial breathing by the rescuer is necessary to 
maintain a flow of oxygen within the victim’s body. Oxygen is forced through the body 
by compressions performed by the resuer on the sternum. To be effective, the victim’s 
airway must be open and unobstructed 

If breaths into the victim do not successfully go in, it is necessary for the rescuer to 
use the operator retilt head. This is the first action to be taken in attempt to successfully 
enable oxygen to enter the victim’s body. It is followed by a second attempt of the give 
two breaths operator. 

In the event of an obstructed airway, perform abdominal thrusts is an operator to 
dislodge a foreign object. Abdominal thrusts are performed after first retilting the 
victim’s head and a second attempt to provide two breaths is unsuccessful. After 
performing abdominal thrusts, the object, if present, should be removed by performing a 
finger sweep. 

Perform finger sweep is conducted following the abdominal thrusts. The intent is 
to dislodge a possible object which may be blocking the victim’s airway and preventing 
oxygen from entering the body. 

The operator check pulse is a necessary step in the CPR procedure because 
performing chest compressions on a victim who has a pulse can result in serious medical 
complications. Emergency breathing should be provided to a victim who has a pulse but 
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is not breathing. For the victim who is not breathing and who does not have a pulse. 
CPR procedures should be initiated immediately. 

When the heart ceases beating, blood no longer circulates, which deprives the body 
of oxygen. The victim will stop breathing due to a shutdown of the respiratory system. 
A person with no pulse will thus not be breathing. However, a person who is not 
breathing may have a pulse. In this case, it is necessary for the rescuer to perform 
emergency breathing. This is a high level operator which actually consists of the 
repetitive use of give two breaths operator as well as the recheck pulse operator. This 
cycle is performed until such time as the victim is breathing on their own or their pulse 
has also stopped, in which case chest compressions associated with CPR become 
applicable. 

One of the two options for contacting professional medical services is instruct 
someone to phone paramedic. If assistance is available, they should be instructed to 
contact professional emergency medical services after the resuer has determined the vital 
signs of the victim. 

The second option for contacting professional medical services is for the rescuer 
themselves to phone paramedic. If assistance is not available, it is necessary for the 
rescuer to first perform CPR for at least one minute and then temporarily cease CPR to 
contact professional emergency medical services. CPR should then be immediately 
resumed. 

Temporarily cease CPR is not a CPR operator per se. It is performed by the 
rescuer if assistance is not available and they must personally contact professional 
medical services. As such, it is only performed in conjunction with the phone paramedic 
operator. 
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Locate compression position is a prerequisite to the performance of chest 
compressions. Not locating the correct position could nullify the significance of 
performing chest compressions. 

Perform fifteen compressions causes the the oxygen the rescuer has breathed into 
the victim to be forced throughout the body. Prior to performing these compressions, the 
correct compression position must be located. 

The essence of CPR is perform compression/breathing cycles. This consists of 
the rescuer providing breaths to the victim, followed by chest compressions to force the 
oxygen through the victim’s body. Chest compressions should never be performed on a 
person with a pulse. Therefore, periodic checks for a pulse should be perfonned. This 
higher level operator is used in the latter portion of the CPR procedure. It’s used in lieu 
of multiple instantiations of the two low level operators, perform fifteen compressions 
and give two breaths. 

Recheck pulse is perfonned to ensure chest compressions are not perfonned on a 
victim with a pulse. If compressions are performed on a person with a pulse, serious 
medical complications may arise. 

Stop bleeding is not actually a CPR operator, but is included to provide more 
realism. It is important for a rescuer to realize that CPR always takes precedence over 
other first aid actions. It is performed only if the victim is bleeding and is also breathing. 
The rescuer must be primarily concerned with the pulse and breathing of the victim. 
Bleeding must be ignored if the victim has no pulse rate and/or is not breathing. 

C. TRAINING PROGRAMS 

The American Red Cross Adult CPR course was designed for the general public. 
Anyone thirteen years of age or older or who has completed the seventh grade anti 
expresses an interest in learning CPR procedures is encouraged to take the course. The 
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duration of the course is six hours and can be taught in either one session or split into two 
three hour sessions. To maintain Red Cross certification, retraining is required on an 
annual basis. The course includes three components: a student workbook, six films, anti 
practice sessions. Participants read the workbook and answer review questions at the entl 
of each chapter. Films are interspersed throughout the course. They include real-life 
emergencies and show demonstrations of the first aid skills being taught. Practice 
sessions and skill tests allow students to actually practice the learned skills. Each student 
must also pass a written test to receive a course completion certificate. [Ref. 1] 



25 



IV. CPR TRAINING. AN ICAI APPROACH 



A. SYSTEMS ORGANIZATION 

The CPR Tutor is an ICAI system which utilizes the Socratic tutoring methodology. 
It was developed and implemented on a Digital Equipment Corporation VAX 
minicomputer using the C-Prolog language. The design is based on the interaction of the 
four primary modules discussed in chapter two, section C. These are: 

1. Expert Module 

2. Tutor Module 

3. Student Model 

4. User Interface 

Figure 4.1 illustrates the interrelationships of these modules. Also shown is their file 
location in the CPR Tutor program." 

B. EXPERT MODULE 

The expert module of an ICAI system consists of two major parts. These are the 
inference engine and the knowledge base. 

1. Inference Engine 

The inference engine used in the CPR Tutor prototype is an application of 
means-ends analysis, a classic technique used to solve search problems by abstraction. 
Using double recursion to decompose the CPR procedure, means-ends analysis reasons 
top-down from abstract goals, with the "ends justifying the means." The means-ends 
analysis Prolog program used in the CPR Tutor prototype was written by Professor 



2 See Appendices D and E for a listing of these files. 
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Figure 4. 1 CPR Tutor Structural Model 
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Rowe. The top-level rule is a recursive means-ends predicate of four arguments: State, 
Goal, Oplist and Goalstate. The State is a complete list of the facts which are true in a 
state. In the CPR Tutor prototype the single fact person-collapsed was chosen to be the 
starting state. The Goal is a list of facts that are required to be true in the goal state (or 
partial description of the goal state). The Goal chosen for the CPR application was 
victim is breathing andor paramedic is on scene. The Oplist is the list of operators that 
are required to reach the goal state from the starting state. This list is always initially the 
same. However, it changes as random substitutions of facts are made. The Goalstate is 
the complete list of facts which are true in the goal state. [Ref. 12] 

Professor Rowe [Ref.l2:p.270] describes the operation of the means-ends 
program as follows: 

This recursive program has a single basis step (the first line), which says we don’t need 
any operators to solve a problem in which the starting state includes all the goal facts. 
The rest of the lines are a single induction step, which ..has two recursive calls: the 
first for the preconditions, the second for the postconditions. The lines say to first 
compute the list of facts different between State and Goal, and find a recommended 
operator for some subset of those facts. Look up the preconditions of the operator and 
recursively call means-ends to figure how to satisfy them. Then look up the deletion 
postconditions and delete them from the final state resulting from the precondition 
recursion; look up the addition postconditions, and add them to that state. Now we 
have the state after application of the original recommended operator. So recursively 
call means-ends to figure how to get from here to the original goal. The final operator 
list for the whole problem is the appending together of the precondition-recursion 
operator list. 

A complete listing of this unchanged program used as the inference engine in the expert 
module in CPR Tutor is contained in Appendix E. 

2. Knowledge Base 

Cardiopulmonary resuscitation is a combination of artificial respiration and 
manual artificial circulation. These two primary actions can be further decomposed into a 
series of basic sub-actions, the application of which is not arbitrarily ordered. CPR can be 
considered a procedural evolution from a starting state to a goal state via intennediary 
states. Because most of these abstracted states are strongly ordered in tire CPR process, 
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there exists nearly a unique recommended solution path, i.e., recommended application 
of operators from the start state to the goal state. Deviations from this path in the 
means-ends program can occur only as a result of a random side effect. One example of 
such a random change in state is a deletion of the fact victim is breathing and the addition 
of the fact victim is not breathing. When the victim is breathing no action, other than to 
standby to assist, is required of the rescuer. However, it is necessary that the rescuer be 
knowledgeable of what actions are necessary should the victim cease breathing. The 
random generation indicated above is designed to test the student’s knowledge of what to 
do in this event and prompts the continuance of the tutoring session. 

The knowledge-base operators must be clearly identifiable and there must 
exist a recommended ordering among them. This recommended order, however, need not 
be predetermined by a list. Instead, each operator has one or more associated 
recommended predicates: 

recommended([<resultant-fact>], <operator>). 

which indicate the facts that application of the operator will help achieve. 

Also associated with each operator must be a precondition fact and a 
postcondition fact. Preconditions are the prerequisites required for the application of 
the operator. Postconditions are the changes that occur when an operator is applied. 

Two-argument facts identify preconditions. The first argument is the operator 
and the second argument is the list of applicable prerequisites for the application of the 



3 The recommended, precondition, and postcondition predicates are necessary input to Professor Rowe’s means- 
ends analysis program which serves as the expert module’s inference engine. As such, the formats of each are 
predetermined. 
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specified operator. The format for precondition facts is as follows: 



precondition(<operator>,[<prereq-factl>,<prereq-fact2>, ...]). 

If no precondition exists for an operator, i.e., it can be applied at any time, the null 
condition, [], is used. The precondition facts used in the CPR Tutor prototype are 
displayed in Figure 4.2. 4 

Postconditions can either add new facts, delete facts, do both, or do neither. 
Two kinds of postconditions are thus associated with each operator, addpostconditions 



precondition(check_if .breathing, 

[on_back( victim), open(airway), not(breathing(victim)), not(stopped_breathing)]). 
precondition(recheck_pulse, 

[unconscious(victim), performed!’ compression breathing cycles’)]). 
precondttion(open_airway, [on_back(victim), unconscious(victim)]). 
precondition(perform_abdominai_thrusts, [retilt(head), given(’first pair of breaths’)]). 
precondition(perform_finger_sweep, [performed! ’ abdominal thrusts’)]). 
precondition(perform_emergency_breathing, 

[unconscious(victim), observed!’ victim not breathing’), observed(pulse)]). 
precondition(perforrn_three_compression_breathing_cycles, 

[perfonnedf ’fifteen compressions’), given(’second pair of breaths’)]). 
precondition(phone_paramedic, [unavailable(assistance), temporarily_stopped(cpr)]). 
precondition(stop_bleeding, [bleeding(victim)]). 
precondition(yell_for_help, []). 



Figure 4.2 CPR Tutor Sample Preconditions 



4 See also Appendix D. 
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and deletepostconditions. The basic format of each is similar to that for preconditions: 



addpostcondition(<operator>,[<assert-factl>,<assert-fact2>,...]). 

deIetepostcondition(<operator>,[<delete-factl>,<deIete-fact2>,...]). 

Real world applications, however, are not always so cut-and-dried. In many applications, 
including CPR, the same operator can have different effects in different circumstances. 
An example is the application of the operator give breaths. This operator is applied 
numerous times in the the process of providing CPR. It is necessary to assert which 
iteration of give breaths has been applied each time the operator is employed. To allow 
this flexibility, multiple three- argument postcondition predicates can be used for 
applicable operators, in addition to the standard two argument format. 5 The fonnat of this 
three-argument form is: 

addpostcondition(<operator>,[<prereq-factlist>],[<assert-factiist>]). 

deletepostcondition(<operator>,[<prereq-factlist>],[<delete-factlist>]). 

Figure 4.3 contains a sampling of the various two and three-argument postcondition facts 
used in the CPR Tutor. 

To more accurately reflect real-life circumstances it necessary to allow the 
possibility of randomness. For example, when the rescuer checks the victim’s pulse, a 
pulse may or may not be present. Thus, although each operator has obligatory 
postcondition facts, other facts can be deleted and/or inserted in the new state through the 



5 Tlns enhancement was developed by Professor Rowe to allow increased flexibility. 
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deletepostcondition(open_airway, []). 
addpostcondition(open_airway, [open(airway)]). 

deletepostcondition(perform_emergency_breathing, [observed(pulse)]). 
addpostcondition(perform_emergency_breathing, 

[given(’first pair of breaths’)], [observed(’no pulse’)]). 
addpostcondition(perform_emergency_breathing, 

[not(given(’ first pair of breaths’))], [still_no_pulse]). 
addpostcondition(perform_emergency_breathing, 
[error-in-perform-emergency-breathing]). 

deletepostcondition(perfonn_three_compression_breathing_cycles, 
[performed(’ fifteen compressions’), given(’second pair of breaths’)]). 
addpostcondition(perform_three_compression_breathing_cycles, 
[performed! ’compression breathing cycles’)]). 

deletepostcondition(give_two_breaths, 

' [stopped_breathing, performed! ’finger sweep’)]). 
addpostcondition(give_two_breaths, 

[phoned(paramedic), still_no_pulse] , 

[given(’sixth pair of breaths’)]). 
addpostcondition(give_two_breaths, 

[on_back( victim), open(airway), performed! ’fifteen compressions’)], 
[given! ’second pair of breaths’)]). 
addpostcondition(give_two_breaths, 

fopen(airway), on_back(victun), not(phoned(paramedic))], 

[given!’ first pair of breaths’)]). 

addpostcondition(give_two_breaths, [error-in-give-two-breaths]). 

deletepostcondition(recheck_pulse, [phoned(paramedic)], 

[performed! ’compression breathing cycles’)]). 
deletepostcondition(recheck_pulse, []). 
addpostcondition!recheck_pulse, [still_no_pulse]). 



Figure 4.3 CPR Tutor Sample Postconditions 
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predicate randsubst. 6 The format for this predicate is as follows: 



randsubst! <operator>,[[<delete-factl>,<assert-factl>, probability l>,<optionaI-nisgl>], 
[delete-fact2>,<assert-fact2>,probability2>,<optional-msg2>], ...]). 



Figure 4.4 contains a listing of the randsubst facts used in the CPR Tutor. 



randsubst(check_pulse, [[observed! ’no pulse’), observed(pulse), 0.2]]). 
randsubst(open_airway, [[unavailable! assistance), available!assistance), 0.3, 
’Someone has responded to your yell for help.’]]). 
randsubst(perform_emergency_breathing, 

[[unconscious(victim), unconscious(victim), 1.0, 

’The heart has stopped beating. What should you do now?’]]). 
randsubst(position_victim, [[unavailable! assistance), available(assistance), 

0.3, ’Someone has responded to your yell for help.’]]). 
randsubst(standby_to_assist, [[observed! ’victim not breathing’), 
observed! ’victim not breathing’), 1.0, 

’Breathing has stopped. What should you do now?’]]). 
randsubst(stop_bleeding, [[breathing(victim), observed(’victim not breathing’), 
0.4, ’Bleeding is stopped. However, the victim has stopped breathing.’]]). 
randsubst!yell_for_help,[[unavailable!assistance), available(assistance), 0.3, 
’Someone has responded to your yell for help.’]]). 
randsubst(give_two_breaths, 

[[given! ’first pair of breaths’), obstmcted(airway), 0.3, 

’Airway is obstructed - you are unable to breathe air into the victim.’]]). 



Figure 4.4 CPR Tutor Random Substitutions 



'This was an enhancement developed by Professor Rowe to allow for randomness. 
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C. KNOWLEDGE ACQUISITION 



The CPR domain expertise was derived solely from a subset of the workbook 
material utilized by the American Red Cross to conduct formal CPR classes. Although 
this represents a reliance on a single expert instead of multiple experts as recommended, 
it was deemed adequate for the development of the CPR Tutor prototype. This decision 
was based on the prototypical nature of the CPR Tutor, the relatively limited length of 
available time for its development, and the fact that many medical experts were 
consulted in the formulation of the workbook itself. A operational version of the CPR 
Tutor, however, would benefit from the direct expertise of the actual medical experts. 

Within the workbook, a skill test is provided which tests the student on their correct 
application of the CPR operators to a predefined scenario. This scenario unfolds as the 
student proceeds. For example, when the student performs the operator check for 
breathlessness, the instructor says "No breathing". The students acknowledges by 
repeating the phrase "No breathing". 

Randomness, however, is not a factor in the American Red Cross skill test. The 
mstructor does not, for example, arbitrarily select "No breathing" as opposed to 
"Breathing" as the response to give to the student. The direction is clearly defined by a 
script type format in which the instructor’s response is given. For the development of the 
CPR Tutor, however, these junctures provided the most logical points for randomness. 
The expertise on how to respond to a direction other than the one taken in the skill test 
was derived from reading material provided elsewhere in the workbook and/or in the 
instructor’s manual. For example, the skill test follows the assumption that someone else 
is available to assist the primary rescuer, i.e., the user of the CPR Tutor. Therefore, 
instruct someone to phone paramedic is one of the predefined operators that the student 
needs to perform to successfully pass the skill test. In textual material which follows the 



34 



skill test, the student is provided the information on what to do if no one responds the the 
rescuer’s yell for help. It does not merely list operators which should be performed, but 
instead states the rescuer should perform CPR, i.e., compression-breathing cycles, for at 
least one minute prior to going to a phone themselves to call the paramedic. The rescuer 
should resume CPR as soon as possible thereafter [Ref. 1]. 

In transposing this expert knowledge into the means-ends analysis format required 
by the CPR Tutor, it was necessary to first define the applicable operators and their 
corresponding recommended, precondition, and postcondition facts. The process of 
creating these facts can perhaps best be explained by way of a couple examples. 

One of the more straightforward operators was open aii~way. To open the victim’s 
airway, it is physically necessary for the victim to be on their back. It is also not logical 
to perform this operator on anyone who is not unconscious. The precondition: 

precondition(open_airway, [on_back(victim), unconscious(victiin)]), 

was used to capture these facts. Opening the airway does not delete any previously 
asserted facts, but its performance does presumably cause an open airway. Thus the 
following recommended and postcondition facts are applicable: 

recommended([open(airway)],open_airway). 
deIetepostcondition(open_airway, []). 
addpostcondition(open_airway, [open(airway)]). 

Because this is one of the earliest operators performed, it is possible that someone could 
respond to the rescuer’s earlier yell for help while this operator is being performed. With 
an assigned thirty percent probability of someone responding to the earlier yell for help 
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during the performance of the open airway operator, the following random substitution 
fact was created: 

randsubst(open_airway, [[unavailable(assistance), available* assistance), 

0.3, ’Someone has responded to your yell for help.’]]). 

When randomness was employed, complications in defining the means-ends 
analysis facts arose. For example, if assistance is available, this other person should be 
instructed to phone the paramedic after the victim’s pulse has been checked and prior to 
the rescuer locating the compression position. This implied that a fact such as help is 
phoned should be a precondition for the compression position being located. However, 
this could not be the case because, if help did not respond, the help is phoned fact would 
not be applicable. In fact, it would be a wrong action on the student’s part. Therefore, 
the precondition: 

precondition(locate_compression_position, [observed(’no pulse’), 
observed(’victim not breathing’), not(avai!able(assistance))]). 

was used. The fact not(available(assistance )) was used to represent the fact that help, if 
previously available, was no longer available at that point because the available assistant 
had left to phone the paramedic. This was a result of the deletepostcondition fact 
associated with the operator instruct someone to phone paramedic. If help had never 
responded to the yell for help operator, the precondition would also be met. 

Thus, in representing the knowledge contained in the American Red Cross CPR 
workbook I Ref. 1], similar assignments were made for each of the operators. Some 
proved to be very straightforward in their translation into means-ends analysis facts. 
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Others, however, required adjustments in the code from what originally might have 
seemed sufficient. This was directly attributable to the implementation of randomness. 



D. TUTOR MODULE 

The tutor module 7 represents a distinguishing feature of ICAI systems over the more 
traditional CBI approach, in that the teaching strategies are separated from the expert 
knowledge base. In the CPR Tutor prototype, the tutor module is basically a stand-alone 
system which could be utilized to tutor any domain which can be represented as a search 
problem for means-ends analysis. For example, a more general version of this same tutor 
has been used to provide training to a Navy fire team leader in combatting a fire aboard a 
Navy vessel. 

The purpose of the tutor module is to monitor the status of the student model and 
thus guide the course of future dialogue between the ICAI system for CPR and the user. 
To meet this purpose, it is necessary for the inclusion of information about effective 
teaching strategies in the tutor module. The tutoring rules used in this module are 
handled by the five argument predicate handIe_studentop. The major tutoring 
strategies used by CPR Tutor include the following: 

- OK. 

Reflects that the student’s response matches that of the expert. This is used for 

identical matches as well as nopref conditions. 

- The operator you now need to perform is: <operator>. 

This prompt is given in response to the user’s request for help. 

- <Warning message> presented on a cleared screen. 

A serious infraction on the user’s part results in a specific warning message. 



7 Tlie tutor module is implemented by the mctutor program developed by Professor Rowe. It is contained in Ap- 
pendix E. 
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- <Warning message> presented on the same screen. 

A less serious infraction on the user’s part results in a specific warning message. 

- That operator requires that <required preconditions list>. 

Indicates a mandatory precondition must first be satisfied before the operator can be 

applied. This violation is less severe than the above two cases. 

- That will not affect anything. 

The action chosen by the student will have no affect on the current state nor on the 

overall solution. 

- That does not seem immediately helpful, but I will try it. 

Allows the user to pursue their selected solution path. 

- I will try it, but it is not recommended or need for the problem. 

Allows the student to apply an operator even though the system sees no need. 

A central issue involved with the use of these tutoring strategies is the 
appropriateness of providing immediate responses to the user’s action as compared with 
temporarily allowing the student to continue down an incorrect path without interruption. 
In many application areas, several solution paths may exist. The CPR procedure, 
however, is not loosely ordered. Much medical research has been conducted in 
determining the optima! ordering of operators. Although deviations from this order may 
not cause serious negative results, the incorrect ordering may, in fact, render the efforts 
of the rescuer ineffective The CPR Tutor, therefore, is typically very stringent in the 
requirement that operators be performed in a specified order; students are not allowed to 
deviate to any great extent. It should be noted that this restrictive nature is not invoked 
by the tutor module itself, but rather by the CPR knowledge utilized by the tutor. When 
necessary to allow the student the option of choosing either of the two operators, the two 
argument predicate nopref is used. This is used in the CPR Tutor in the selection of the 
first two operators; represented by the Prolog fact: 



nopref(check_if_unconscious,yell_for_help). 
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E. STUDENT MODEL 



The student model is a representation of the student’s understanding of CPR 
procedures as perceived by the CPR Tutor system. It is thus a model of the system’s 
knowledge of the student based on their response to the specific situational state 
presented to the student. It is constructed by comparing the student’s response to the 
expert module’s means-ends analysis recommended response. The model is updated 
throughout the tutoring session. 

Ingrained in the metutor program developed by Professor Rowe is a dynamic 
student model: a stack representation of the applied operators. Throughout the tutoring 
session, it was the current version of this stack which was used by the means-ends 
analysis subprogram to determine the tutoring strategy to be used. By analyzing the 
stack, a theory was developed as to what the student was actually trying to do. Although 
the human mental process isn’t normally thought of in terms of stacks, it often seems like 
such a structure is used in the planning of complicated problems. The use of stacks in 
modeling the student was a subtle, yet complicated process. 

A second use of the student model was much less complicated. It involved the 
creation of lists which captured the process used by the student. These lists were 
presented to the user at the completion of each tutoring session. They include a list of all 
the operators chosen by the user throughout the session, the operators for which the user 
requested help, and the operators which the user had difficulty in applying. Additionally, 
the student’s total response time was calculated. This was kept for two purposes. One 
was to enforce some sense of urgency in knowing what do in each situation. The second 
was to present a relative overall response time measurement indicator to the user at the 
completion of the session. As such, diagnostics were provided to the user from which 
they could analyze their demonstrated misunderstandings. This self analysis approach 
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was used rather than a "score" because the author felt the domain of CPR, a life-or-death 
matter, should not be measured in terms of partial correctness. A detailed description of 
the specific diagnostics presented to the user are discussed later in this chapter in the user 
interface section. 

F. USER INTERFACE 
1. Input 

The CPR Tutor prototype uses primarily a menu-based approach to obtain user 
input. The spcifice menus presented to the user are dependent on the experience level 
chosen, i.e., novice, intermediate, advanced. 

a. Menu Advantages 

Menus offer some primary advantages in their use. Firstly, an easy way is 
provided for the user to enter such data as user-experience level and desired-system 
option, i.e., HELP, Review CPR procedures, CPR skill test and QUIT, Subsequently, 
menus allow the user to easily interact with CPR Tutor, entering their recommended 
operator to the given state in the scenario. 

Menus have the advantage of being especially easy to use for slow and/or 
inaccurate typists. There exists a lesser chance for typographical error and a resultant 
misrecognition by the system of the user’s intended response. By being easy to use and 
self-explanatory by their very nature, the student’s energy can be directed at learning the 
CPR procedure and not at how to use the system itself. 

b. Menu Disadvantages 

A primary disadvantage of menus is their restrictive nature. Users are not 
free to enter anything; their choice must be one of the menu items. The use of natural 
language input would seem to be a more natural and less restrictive form of 
communication for the user. Although natural language may ultimately provide the best 
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